Analog circuit simulations, whether purely analog or the analog content of a mixed-signal design, can be performed as part of a DC analysis in which a circuit operating point is determined. Simulations may also be performed as part of a transient analysis in which circuit behavior is determined as a function of time. The analog solution process formulates a system of non-linear differential equations representing the design at the DC operating point or at each timepoint during a transient analysis. It then solves the equations using some iterative technique. The solution to this system of equations gives the DC operating point of the circuit during the DC analysis, or if combined with some numerical integration methods, provides the instantaneous behavior of the circuit at each timepoint during the transient analysis.
During DC analysis or at each solution timepoint, there are two major phases to the solution process: (1) formulating a system of equations by executing the model code for each model instance in the design, and (2) solving this system of equations. Since the equations may be non-linear, a direct solution cannot be performed, and hence these phases are performed within an iterative loop until the sequence of solutions converges upon an acceptable solution. A common iterative technique is Newton-Raphson Iteration. The basic idea of this technique is encapsulated using the following pseudo-code:
foreach ( DC solution or transient analysis trial timepoint) {foreach Newton-Raphson Iteration, i {linearize the system of non-linear equationsabout previous solution i-1formulate system of linear equations Ax = bsolve system of linear equations Ax = b for solution vector,x}}
The solution vector x contains the values of the circuit “unknowns” which may represent the circuit node voltages or other unknowns of interest such as certain currents. The matrix A, commonly known as Jacobian matrix, can be constructed using techniques such as Modified Nodal Analysis (MNA), Nodal Analysis (NA), or other techniques. The vector b, commonly known as Residual vector, is also constructed using such techniques. During any particular Newton-Raphson iteration i, when the system of linearized equations is formulated, the simulator has actually linearized about the previous solution value x (i−1). Thus, for any given iteration, the values present in the Jacobian matrix A and Residual vector b are a function of the solution vector x of the previous iteration. The iterative process continues, building the system Ax=b, and solving for a new value of x, after which a new system Ax=b is built and solved for until successive solutions converge upon acceptable values for the unknowns in x.
The process is complicated by the fact that at a particular trial timepoint, the iterations may fail to converge, or may converge too slowly. During a transient analysis, the analog simulator may reject the trial timepoint that failed to converge and attempt to obtain the circuit solution at a different timepoint. This is repeated until convergence is achieved and before moving forward with time and continuing the process. There may be also other reasons for rejecting a trial timepoint and choosing an earlier timepoint, which further complicate the process.
The selection of trial timepoints is algorithmically determined, as is the decision of when to reject a particular timepoint. As such, a sequence of trial timepoints may arise as follows:0.0 0.1 0.3 0.5(rejected) 0.4 0.45 0.52 0.62 0.8 1.2(rejected) 0.95
The timepoint sequence is generally increasing. But it is not monotonically increasing because solutions at times 0.5 and 1.2 are rejected. After the first rejection, the timepoint is reduced to 0.4, and after the second rejection, it is reduced to 0.95. After each rejection, simulation continues with a new (reduced) timepoint.
The repeated nature of building and solving such systems of equations for each iteration of each timepoint explains why analog simulation is considered slow or expensive compared to digital simulation, which operates at an entirely different level of abstraction and uses a completely different algorithm. Analog simulation involves solving systems of equations, which translates into matrix inversion operations, and these are computationally expensive.
An analog hardware description language (AHDL), or mixed signal description language such as Verilog-AMS, or the VHDL-AMS, provides a user a capability of modeling his design at a much higher level of abstraction than that of using primitive objects such as transistors, resistors, etc. It can thus be used in, and in fact it is a prime enabler of, top down design methodologies for analog and mixed-signal designs. Such languages allow a user to describe the analog functionality of his design in a manner somewhat similar to how a digital designer today uses one of the HDL's such as Verilog or VHDL to describe his digital circuit behavior. The analog functionality is described in a high level language, which consists of one or several blocks of concurrent behavior, within which there are a number of statements of sequential behavior. Examples of such languages which enable this level of modeling analog behavior include SpectreHDL, Verilog-A, Verilog-AMS and VHDL-AMS. One example using Verilog-A syntax or Verilog-AMS syntax is given below:
// this is a comment. Declare a modulemodule dac_8bit_ideal (vd7, vd6, vd5, vd4, vd3, vd2, vd1, vd0, vout);//declare its terminal listelectrical vd7, vd6, vd5, vd4, vd3, vd2, vd1, vd0, vout;//declare its parametersparameter real vref = 1 from [0:inf);parameter real trise = 0 from [0:inf);parameter real tfall = 0 from [0:inf);parameter real tdel = 0 from [0:inf);parameter real vtrans = 2.5;real out_scaled; //declare a variable representing output (scaled)// define the analog behavior using sequential statementsanalog beginout_scaled = 0;out_scaled = out_scaled + ((V(vd7) > vtrans) ? 128:0);out_scaled = out_scaled + ((V(vd6) > vtrans) ? 64:0);out_scaled = out_scaled + ((V(vd5) > vtrans) ? 32:0);out_scaled = out_scaled + ((V(vd4) > vtrans) ? 16:0);out_scaled = out_scaled + ((V(vd3) > vtrans) ? 8:0);out_scaled = out_scaled + ((V(vd2) > vtrans) ? 4:0);out_scaled = out_scaled + ((V(vd1) > vtrans) ? 2:0);out_scaled = out_scaled + ((V(vd0) > vtrans) ? 1:0);// contribute to the output of this module.// Affects Jacobian matrix A, Residual b.V(vout) <+ transition( vref*out_scaled/256, tdel, trise,trfall ) ;endendmodule
Within the analog begin/end pair of the above model, the individual statements, which are delimited by semi-colons, are executed in sequence. Such a model could also include if-then-else statements, C-like switch statements, etc.
The last line of the analog block:V(out)<+transition(vref*out_scaled/256, tdel, trise, tfall);is used to specify that the value of the expression, vref*out_scaled/256, is to be driven onto the output pin of the module, where the previous lines were used to calculate the value of the variable out_scaled.
Consider again the analog simulation process:
foreach ( DC solution or transient analysis trial timepoint) {foreach Newton-Raphson Iteration, i {linearize the system of non-linear equationsabout previous solution i-1formulate system of linear equations Ax = bsolve system of linear equations Ax = b for solution vector, x}}During the formulation of the system of linear equations Ax=b, the analog simulator evaluates the model code for each device or model instance in the design. In the process, each device contributes entries to the Jacobian matrix A, and the Residual vector b. As mentioned previously, these contributions are functions of the previous value of the unknown vector x. In addition to built-in primitives such as resistors, and MOS transistor models such as Bsim3v3, each analog behavioral model is also responsible for loading its contributions in the matrix x and vector b. Using the example above, the contribution into matrix A involves the value of the expression, “vref*out_scaled/256”, which is loaded in such a way as to affect the value of the unknown variable “out.” Here “out” is represented somewhere in the solution vector of unknown x. The final value of “out_scaled” used in the expression is derived by executing the previous sequential statements. Each sequential statement of analog behavioral code for each model is thus “evaluated,” in order to create matrix A and vector b. The users find interest in evaluation of the behavioral statements because the result of executing these user-written statements affects matrix A and vector b and hence affects the behavior of the circuit/design as a whole. Since the evaluation of the statements within the analog block is sequential, it makes sense to attempt to provide a debugging capability to allow the user to interactively single-step through the evaluation of such statements, inspect the values of the variable and other objects contained within and modified by the statements, create breakpoints on individual statements, breakpoints on individual variables changing value, follow the evaluation of if-then-else blocks, and generally allow the user to determine if the statements in his model function correctly or incorrectly.
When an AHDL or a mixed-signal behavioral modeling capability is added to an analog circuit simulator such as Spectre/SPICE, or a mixed-signal circuit simulator such as AFFIRMA AMS, the analog behavioral code is executed by the simulator's analog solver at every Newton-Raphson iteration of every trial timestep during a transient analysis, just as the model code (equations) for built-in primitive semiconductor device models are executed. During the Newton-Raphson iteration process, the simulator calculates new entries for the RHS vector and the Jacobian matrix, which are functions of the current solution vector. For behavioral code such as an analog block in Verilog-AMS or SpectreHDL, this involves evaluation of the behavioral code.
As part of a transient analysis, the simulator calculates a new trial timepoint and performs the Newton-Raphson iteration at that timepoint. It then decides whether to accept the solution at that timepoint and continue (advance time) or reject the solution at that timepoint and back up time, redoing the iterations at a “sooner” timepoint.
The prior art solution to the problems of interactive debugging is to stop the simulation before every evaluation of every analog behavioral statement, and present an interactive prompt to the user. The user could then interactively traverse his design, inspect signal values, or step and execute the next behavioral statement (again stopping before the next one), and create breakpoints, etc.
The implementation of the prior art involves instrumenting the code generated for the analog behavioral statements, inserting a special opcode at the beginning of each statement. The engine which evaluates the analog behavioral statements is then modified to pause and present the user with an interactive prompt at each of these special opcodes, not continuing until the user issues a “run”, “continue” or “step” command.
This solution, or some variation thereof, is common for debugging sequential operations, and is implemented in some form in many conventional programming language debugging tools as well as in digital simulators in the EDA marketplace. The basic idea in such kind of solution is to provide the capability of stopping to go interactive before every single statement is executed.
The disadvantages of the prior art solution are numerous. For examples:
1. Non-Monotonicity of Time. The transient simulation algorithm described above is complicated by the fact that a trial timepoint solution may be rejected for various reasons. Such reasons include synchronization with the digital engine in a mixed signal simulation, violation of the Local Truncation Error (LTE) requirements in the integration method used as part of the transient analysis to handle the differential part of the non-linear differential equations, and device limitation, etc. Because of the rejection of some timepoints, the simulation time is not moving monotonically forward. Users such as circuit designer and modeling engineer are not generally familiar with the underlying intricacies of analog simulation and transient analysis algorithms. They may consider time to be monotonically increasing. If they observe the value of time moving forwards and backwards during debugging, they may feel confused. Additionally, in order to verify that the time-dependent behavior of their models is correct, the users need to see the value of simulation time during debugging. Therefore, simply hiding the time from users is not a viable solution.
2. Rejected Timepoints. As previously described, solutions calculated at any given timepoint may be rejected for various reasons. If a user is single-stepping through his models looking for a bug, he has to go through a lengthy single-stepping process in order to debug his model and/or design—he has to single step through every statement of every iteration of every rejected timestep. Since the solutions at these timesteps are then completely discarded by the simulator, the user may have wasted a substantial amount of time while single stepping through these solutions.
3. Newton-Raphson Iteration Process. Since an analog simulator cannot directly solve a system of non-linear equations, it performs an iterative process in which the user's model statements are executed for every single iteration. This is another artifact of simulation that probably does not interest the user. For example, if the user intended to write the following statement:
if (a>b) begin                do something        
end
but instead accidentally used the less-than operator as in
if (a<b) begin                do something        
end
then one single iteration is probably sufficient for him to find this bug. The user is often not interested in single stepping through all the Newton-Raphson iterations. In many cases, he probably desires to remain blissfully ignorant that there is any iterative process being performed at all. Language users tend to think of sequential operations and usually are unaware of the analog simulator's requirements on iterative processes to solve non-linear equations. Again, it is confusing to the user in an iterative situation and time consuming and wasteful to stop before every evaluation of every statement.
While allowing to debug each iteration may be useful for an advanced user who tries to debug convergence problems in his modules, it would be more useful to abstract these iterations away for the more typical user who simply tries to debug logic and control issues such as the less than operator example illustrated above. When the variables a and b in the example depend on some node voltages, the if statement, from one iteration to the next, may evaluate first to true and then to false because the values of a and b depend on the current “guess” at the solution. This may further confuse the user and waste even more time as he single steps through each iteration and observes what appears to be radically different behavior from one iteration to the next.
4. Object Value-Change Breakpoints. A value-change breakpoint is a concept of interrupting the simulator and presenting the interactive prompt to the user whenever a particular variable of interest to the user is written to or changes value. Since a variable may be written to on each of many Newton-Raphson iterations, it is demanding upon the user to interrupt the simulation for each of these. A generic “watch” on all write attempts to a variable as would be implemented using standard sequential program debugging approaches would thus result in a lot of wasted stopping points. Again, some of these may be on timepoints that are subsequently rejected, which is completely wasteful.
In addition, if non-monotonicity of time exists, a user who pays close attention to changes in a particular variable but not-very-close attention to the actual simulation time may observe what he considers to be very strange behavior. For example, a variable that stores the simulation time or some function of the simulation time would be expected to increase monotonically. However, because the timepoint sequence is not increasing monotonically, the variable cannot increase monotonically either. This, again, leads to a potential source of user confusion and lack of confidence in the product. Another drawback would be for the user who is watching value changes on a variable that is supposed to represent a voltage on some circuit node, or some function of the voltage. If he expects the voltage to increase linearly, then he would expect the values of the variable to increase linearly also when each breakpoint is reached. However, due to the nature of Newton-Raphson iteration, a succession of guesses at a node voltage may oscillate quite a bit before finally converging on the actual solution. While the actual solutions may be increasing monotonically, the individual solutions as part of the Newton-Raphson process are not likely to be, thus again confusing the user who is monitoring a variable that depends linearly on the node voltage.
5. Nodal-Value Change Breakpoints. A user may be interested in interrupting the simulation whenever a particular node changes value, or changes value “significantly”. For example, when a user tries to debug simulation “glitches”, if he observes the value of the node solution during every Newton-Raphson iteration, he might observe some wildly varying per-iteration values on the node before it finally converges upon the actual solution. The converged solution may be still unchanged from the previously accepted solution, and thus not of interest from a “glitch-debugging” perspective. This effect can be even further exaggerated by the timestep rejection process.
6. Performance Degradation. By having the simulator check if it needs to present an interactive prompt before every single evaluation of every statement, for every iteration and for every trial timepoint (accepted or not), simulation time is wasted. Hence this method is computationally inefficient and can degrade simulation performance by performing many possibly redundant checks. Additionally, for object value change/access breakpoints, much time may be spent in checking every access of a particular variable, contributing to further inefficiency.
7. Exposure of Timestep Selection Algorithm. An analog transient simulation algorithm involves choosing trial timepoints and attempting solutions, while possibly rejecting some timepoints in favor of other timepoints. The user needs to know the current value of time while interactively debugging his model in order to determine if it is exhibiting the correct time-dependent behavior. Much of what distinguishes one analog simulator from another boils down to the specific algorithms used by the analyses, including the heavily used transient analysis. By allowing the user to single step through every iteration of every timepoint, rejected or otherwise, in a simulation, and showing him the current value of time (i.e. informing the user of the current timepoint), the sequence of timepoints chosen by the algorithm is exposed. This opens up the possibility of reverse engineering the timestep selection algorithm if the user is a competitor.
8. Exposure of Timepoint Rejection Algorithm. A drawback of exposing every single timepoint, whether accepted or not, is that the algorithm which decides when a particular timepoint is rejected is also exposed. It is easy to determine which are the accepted timepoints, and thus the rejected timepoints become apparent. Choosing which timepoints to reject is also an important and distinguishing characteristic of a particular simulator. It enables certain optimizations, such as, the simulator decides to reject the timepoint before convergence is even reached, if convergence is “not likely to happen” or is “happening too slowly”, in favor of another timepoint that is likely to converge more quickly. Again, exposing the rejected timepoints using the previous debugging solutions opens up the possibilities of reverse engineering this algorithm.
9. Exposure Of Other Timepoint-Related Algorithms. A simulator may decide to reject a solution for reasons other than non-convergence. These reasons may also include synchronization reasons in a mixed-signal simulator. The prior art solution could thus expose to competitors the algorithms (synchronization and other) involved in mixed-signal simulation tools which contain the analog solution engine as part of a larger product. In other words, it is not simply the analog simulator that is at stake, but the mixed-signal simulator also.
What is desired is to provide a capability of interactively debugging behavioral models during simulation without need to single step through every statement of every iteration of every timestep, including rejected timesteps.